…e, columnar

Aaron's third pass adds three corrections/expansions:

1. **.NET stored procedures, not just C#.** C# + F# both.
   "i should have said dotnet stored procedures c#/f#
   whoops lol."

2. **Zeta is BOTH event-sourcing and regular database.**
   A façade/abstraction hides the eventing/retraction
   machinery so Zeta can be used "like a normal non-
   eventing database as well." Aaron: "it should be both,
   i can replace my database and my event store with
   Zeta."

3. **Event streaming + regular DB + likely columnar.**
   Columnar storage alongside row-oriented Spine —
   OLAP/analytics/wide-row sparse-projection workloads.

## VISION.md v4

New "Both modes" subsection under Product 1: event-sourcing
mode (native DBSP) + regular-database mode (façade hiding
deltas/retractions) + columnar substrate likely in scope.
Same operator algebra + query IR feeds both modes.

Reaqtor-niche entry updated to ".NET stored procedures
(C# + F# both)" from "C# stored procedures."

Resolved-this-round list extended with the three new items.

## BACKLOG.md additions

Two new P2 entries:
- Regular-database façade design doc with design questions:
  separate NuGet or default surface? How does INSERT/UPDATE/
  DELETE map to deltas without leaking retractions?
  Transaction model?
- Columnar storage substrate design doc with references:
  DuckDB, Arrow, Parquet, ClickHouse, Feldera. Can
  retraction-native columnar expose Z-set deltas? How
  does planner pick row vs column per query?

## Known flake (unrelated)

PR #15 ubuntu-22.04 failed on `Zeta.Tests.Properties.FuzzTests.
fuzz: HLL estimate within theoretical error bound` — known
probabilistic bound occasionally exceeded with unlucky seed.
Flake logged for round 34 DEBT cleanup. Main should be green
on next push.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…e, columnar

Aaron's third pass adds three corrections/expansions:

1. **.NET stored procedures, not just C#.** C# + F# both.
   "i should have said dotnet stored procedures c#/f#
   whoops lol."

2. **Zeta is BOTH event-sourcing and regular database.**
   A façade/abstraction hides the eventing/retraction
   machinery so Zeta can be used "like a normal non-
   eventing database as well." Aaron: "it should be both,
   i can replace my database and my event store with
   Zeta."

3. **Event streaming + regular DB + likely columnar.**
   Columnar storage alongside row-oriented Spine —
   OLAP/analytics/wide-row sparse-projection workloads.

## VISION.md v4

New "Both modes" subsection under Product 1: event-sourcing
mode (native DBSP) + regular-database mode (façade hiding
deltas/retractions) + columnar substrate likely in scope.
Same operator algebra + query IR feeds both modes.

Reaqtor-niche entry updated to ".NET stored procedures
(C# + F# both)" from "C# stored procedures."

Resolved-this-round list extended with the three new items.

## BACKLOG.md additions

Two new P2 entries:
- Regular-database façade design doc with design questions:
  separate NuGet or default surface? How does INSERT/UPDATE/
  DELETE map to deltas without leaking retractions?
  Transaction model?
- Columnar storage substrate design doc with references:
  DuckDB, Arrow, Parquet, ClickHouse, Feldera. Can
  retraction-native columnar expose Z-set deltas? How
  does planner pick row vs column per query?

## Known flake (unrelated)

PR #15 ubuntu-22.04 failed on `Zeta.Tests.Properties.FuzzTests.
fuzz: HLL estimate within theoretical error bound` — known
probabilistic bound occasionally exceeded with unlucky seed.
Flake logged for round 34 DEBT cleanup. Main should be green
on next push.

Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…e, columnar, log-as-truth principle

Aaron's third pass adds three corrections/expansions:

1. **.NET stored procedures, not just C#.** C# + F# both.
   "i should have said dotnet stored procedures c#/f#
   whoops lol."

2. **Zeta is BOTH event-sourcing and regular database.**
   A façade/abstraction hides the eventing/retraction
   machinery so Zeta can be used "like a normal non-
   eventing database as well." Aaron: "it should be both,
   i can replace my database and my event store with
   Zeta."

3. **Event streaming + regular DB + likely columnar.**
   Columnar storage alongside row-oriented Spine —
   OLAP/analytics/wide-row sparse-projection workloads.

## VISION.md v4

New "Both modes" subsection under Product 1: event-sourcing
mode (native DBSP) + regular-database mode (façade hiding
deltas/retractions) + columnar substrate likely in scope.
Same operator algebra + query IR feeds both modes.

Reaqtor-niche entry updated to ".NET stored procedures
(C# + F# both)" from "C# stored procedures."

Resolved-this-round list extended with the three new items.

## BACKLOG.md additions

Two new P2 entries:
- Regular-database façade design doc with design questions:
  separate NuGet or default surface? How does INSERT/UPDATE/
  DELETE map to deltas without leaking retractions?
  Transaction model?
- Columnar storage substrate design doc with references:
  DuckDB, Arrow, Parquet, ClickHouse, Feldera. Can
  retraction-native columnar expose Z-set deltas? How
  does planner pick row vs column per query?

## Known flake (unrelated)

PR #15 ubuntu-22.04 failed on `Zeta.Tests.Properties.FuzzTests.
fuzz: HLL estimate within theoretical error bound` — known
probabilistic bound occasionally exceeded with unlucky seed.
Flake logged for round 34 DEBT cleanup. Main should be green
on next push.

Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>

…C byte encoding

Two new Codex P1 findings on the BLAKE3 receipt-hashing v0 doc:

P1 (line 226) — replay determinism vs current signer set:
The req #4 said "compare commitment vs CURRENT signer-view",
which makes receipt validity time-dependent — the moment the
live signer set rotates, every prior receipt becomes invalid.
Replay-determinism breaks. Fix: validate against the signer
set authoritative at the receipt's claimed `policy_version`
(recoverable from `policy_version` + dispute-process
commitment-opening). Receipt-creation-time race-checking is
moved to the receipt-creation step; the replay gate catches
*forged* commitments only.

P1 (line 157) — canonical text-to-byte mapping:
The `len:u32-be ∥ bytes` framing for variable-length
identifiers (`budget_id`, `policy_version`, `node_id`)
specified the framing but not how to derive `bytes` from
the identifier string. Added explicit binding:
`bytes = NFC-normalised UTF-8 octets` — Unicode Normalization
Form C per Unicode Annex #15, then UTF-8 encoded. NFC fixes
visually-identical-but-byte-different forms (e.g., precomposed
vs decomposed accents); UTF-8 is the canonical text→byte map.
EOF

…C byte encoding

Two new Codex P1 findings on the BLAKE3 receipt-hashing v0 doc:

P1 (line 226) — replay determinism vs current signer set:
The req #4 said "compare commitment vs CURRENT signer-view",
which makes receipt validity time-dependent — the moment the
live signer set rotates, every prior receipt becomes invalid.
Replay-determinism breaks. Fix: validate against the signer
set authoritative at the receipt's claimed `policy_version`
(recoverable from `policy_version` + dispute-process
commitment-opening). Receipt-creation-time race-checking is
moved to the receipt-creation step; the replay gate catches
*forged* commitments only.

P1 (line 157) — canonical text-to-byte mapping:
The `len:u32-be ∥ bytes` framing for variable-length
identifiers (`budget_id`, `policy_version`, `node_id`)
specified the framing but not how to derive `bytes` from
the identifier string. Added explicit binding:
`bytes = NFC-normalised UTF-8 octets` — Unicode Normalization
Form C per Unicode Annex #15, then UTF-8 encoded. NFC fixes
visually-identical-but-byte-different forms (e.g., precomposed
vs decomposed accents); UTF-8 is the canonical text→byte map.
EOF

…th-ferry candidate #3) (#268)

* research: BLAKE3 receipt-hashing v0 design input to lucent-ksk ADR (7th-ferry candidate #3)

Responds to Amara's 7th-ferry BLAKE3 proposal (PR #259) +
Aminata's Otto-90 critiques (PR #263) flagging it belongs in
lucent-ksk rather than Zeta + naming side-channel-leakage and
cryptographic-agility gaps + Otto-91 addition of
parameter_file_sha binding for replay determinism.

v0 hash input set (8 fields, changes marked):

  h_r = BLAKE3(
    hash_version                    // NEW — crypto-agility
    ∥ h_inputs
    ∥ h_actions
    ∥ h_outputs
    ∥ budget_id
    ∥ policy_version
    ∥ parameter_file_sha            // NEW — Otto-91
    ∥ approval_set_commitment       // CHANGED — side-channel
    ∥ node_id
  )

Signature structure adds *_key_version to each signature tuple
for per-key-rotation without breaking historical receipts.

Addresses Aminata's 3 findings:
- Side-channel leakage: raw approval_set → Merkle/sorted-hash
  commitment; read-only observers see a hash, dispute process
  opens it.
- Cryptographic-agility: hash_version prefix + *_key_version
  binding; algorithm downgrade blocked because version is
  inside the hash.
- Approval-withdrawal race (top-3 #2): commitment mismatch at
  replay-time invalidates the receipt.

4 replay-deterministic harness requirements for Zeta-module
consumer side:
1. Same fields = same materialised views byte-for-byte.
2. Unknown hash_version = halt-and-report.
3. Unresolvable parameter_file_sha = halt-and-report.
4. Mismatched approval_set_commitment = reject receipt.

Explicit NOT-scope:
- Doesn't decide signature algorithm (Ed25519 is v0
  assumption, scheme accommodates later).
- Doesn't define hash_version / parameter_file registries
  (lucent-ksk governance artifacts).
- Doesn't define commitment scheme specifics (Merkle vs
  sorted-hash-list; affects dispute only).
- Doesn't implement rotation runbook.
- Doesn't include Bitcoin anchoring (separate trust-model).

7 dependencies to adoption in priority order; Aminata 2nd
pass first; cross-repo lucent-ksk ADR second; Max-specific
asks framed per Otto-90 specific-ask-channel calibration.

This is Zeta-SIDE design input. Canonical ADR belongs in
lucent-ksk per Aminata Otto-90 framing. No adoption until
cross-repo ADR lands.

Max attribution preserved first-name-only. Cross-repo work
on lucent-ksk does not touch Max's substrate directly until
actual coordination warrants — specific-ask channel is the
right escalation.

Archive-header format self-applied — 10th aurora/research
doc in a row.

Lands within-standing-authority per Otto-82/90 calibration.

Closes 7th-ferry absorb candidate #3 of 5. Remaining:
- #1 KSK-as-Zeta-module implementation (L)

Otto-92 tick primary deliverable.

* drain(#268 P2+P2+style+P1 Codex/Copilot): field count + version notation + canonical encoding

Four threads on the BLAKE3 receipt-hashing v0 design doc, all
on the same file.

P2 (lines 120 + 126): "8 fields" header / count text vs the
formula's 9 actual binding inputs (`hash_version` + 8 content
hashes). Reconciled to "9 fields" — the formula was the
source of truth, the count text was the lag.

Style (line 236): version notation inconsistency — `0x01` in
some places, `v0x02` / `v0x01` in others. Standardized on the
byte-literal hex notation `0x01` / `0x02` everywhere; the
"v" prefix doubled up with `hash_version =` already in the
formula and added no information.

P1 (line 132): hash binding used raw `∥` concatenation of
variable-length fields, opening a length-extension /
boundary-shift adversary surface. Added an explicit
`encode(·)` wrapper per field with a canonical-encoding
section: 1-byte version, 32-byte fixed-width digests for
content/policy/commitment hashes, and `len:u32-be ∥ bytes`
length-prefix framing for variable-length identifiers
(budget_id, policy_version, node_id). Forward-compatibility
preserved — future schemes (`hash_version >= 0x02`) can pick
different framing (CBOR / Protobuf / RFC 8949 §3.1 TLV) and
the version prefix tells verifiers which framing applies.

All 4 Codex/Copilot threads (PRRT_kwDOSF9kNM59SMrz,
PRRT_kwDOSF9kNM59SNsm, PRRT_kwDOSF9kNM59SNsy,
PRRT_kwDOSF9kNM59SNs2) addressed in this commit.

* drain(#268 lint): MD032 — line-leading + interpreted as list bullet (wrap fix)

* drain(#268 P1+P1 Codex): replay-determinism on signer view + UTF-8/NFC byte encoding

Two new Codex P1 findings on the BLAKE3 receipt-hashing v0 doc:

P1 (line 226) — replay determinism vs current signer set:
The req #4 said "compare commitment vs CURRENT signer-view",
which makes receipt validity time-dependent — the moment the
live signer set rotates, every prior receipt becomes invalid.
Replay-determinism breaks. Fix: validate against the signer
set authoritative at the receipt's claimed `policy_version`
(recoverable from `policy_version` + dispute-process
commitment-opening). Receipt-creation-time race-checking is
moved to the receipt-creation step; the replay gate catches
*forged* commitments only.

P1 (line 157) — canonical text-to-byte mapping:
The `len:u32-be ∥ bytes` framing for variable-length
identifiers (`budget_id`, `policy_version`, `node_id`)
specified the framing but not how to derive `bytes` from
the identifier string. Added explicit binding:
`bytes = NFC-normalised UTF-8 octets` — Unicode Normalization
Form C per Unicode Annex #15, then UTF-8 encoded. NFC fixes
visually-identical-but-byte-different forms (e.g., precomposed
vs decomposed accents); UTF-8 is the canonical text→byte map.
EOF

* drain(#268 P1+P2 Codex): correct adversary terminology + decouple CBOR/TLV citations

P1 (line 144) — terminology correction:
"length-extension / boundary-shift adversary surface"
incorrectly conflated two distinct attacks. BLAKE3 is built
on a tree-hash construction with finalisation flags — it is
NOT vulnerable to length-extension the way SHA-256 and MD5
are. The actual risk in raw concatenation is boundary-shift
/ collision-by-reframing only. Updated the wording to name
that risk explicitly and added a parenthetical noting that
length-extension is NOT a concern with BLAKE3.

P2 (line 162) — CBOR vs TLV reference correction:
'domain-separated TLV per RFC 8949 §3.1' conflated two
distinct concepts: RFC 8949 is CBOR (tagged data items), and
'domain-separated TLV' is a separate framing concept. Split
into two parallel options: 'CBOR per RFC 8949' (one option)
and 'a domain-separated TLV scheme' (another, no specific RFC
attached because TLV is generic). Future ADR can pick either
or define a custom TLV; the v0 doc no longer mis-cites.

* drain(#268 P1×3 Codex): version-policy gate + retired-key restriction + signed key-version

Three substantive Codex P1 findings on the v0 receipt-hashing design:

P1 (line 229) — version policy gate beyond unknown:
Req #2 only fail-closed on unknown hash_version. Updated to
also reject DEPRECATED versions per a policy registry
(lucent-ksk governance artifact). Prevents forgery under an
old-but-still-mechanically-recognised version that was
retired due to weakness. Historical receipts remain
verifiable for audit; new receipts under deprecated versions
are refused.

P1 (line 211) — retired key versions:
Rotation introduced agent_key_version/node_key_version but
didn't restrict NEW receipts from using retired key versions.
Added: separate registry of retired key versions blocks
creation of new receipts under retired versions; historical
receipts under retired versions remain verifiable
(replay-determinism preserved) but the signing path refuses
to produce more.

P1 (line 203) — signed key-version (authenticated metadata):
The notation `Sign_{sk, *_key_version}(h_r)` was ambiguous
about whether *_key_version was authenticated. If it's
unsigned metadata, an attacker can swap the declared version
to one that points at a public key for a different signature
algorithm. Fix: bind the version INSIDE the signed message
(`Sign_{sk}(version ∥ h_r)`) and verify by recomputing the
signing input from the declared version. Verification block
added showing the explicit lookup + recompute pattern.

Also reframed line 120 to make the field-count reasoning
explicit (Amara's 7 base + hash_version + parameter_file_sha
= 9 v0 fields) so the count claim isn't load-bearing on the
preceding paragraph alone.

* drain(#268 P1+P1 Codex): u32-be encoding for key-version + issuance-epoch gate on deprecated hash_version

Two more substantive Codex P1 findings:

P1 (line 208) — canonical encoding for key-version:
The signature scheme bound *_key_version into the signed
message but didn't specify the byte encoding. Added explicit
`encode_u32_be` wrapper + an Encoding section: 4-byte
big-endian unsigned integer, monotonic from 1, with version 0
reserved for uninitialised. Fixed-width avoids needing a
length prefix (every version is exactly 4 bytes).

P1 (line 260) — issuance-epoch gate on deprecation:
Unconditionally rejecting receipts with deprecated
hash_version breaks audit/replay of historical receipts that
were valid when issued. Updated to issuance-epoch gate:
receipts issued BEFORE the version's deprecation cutoff
remain valid for audit; receipts claiming an issuance epoch
AFTER the cutoff under that version are rejected. Registry
stores (version, deprecated_after_epoch) tuples; verifier
compares claimed issuance epoch against deprecation epoch
for that version.

#521)

* tools(hygiene): lost-files common-locations catalog (Otto-329 Phase 8 substrate)

15 location-classes where lost files commonly accumulate, sorted
roughly by yield-density. Each class has a survey command +
triage protocol.

Aaron's ask (Otto-329 Phase 8 + same-tick reminder): "you keep a
list of lost file common locations i asked you to write it."

I had started Phase 8 by jumping into the search activity without
first creating the catalog. Aaron's catch: the list IS the
substrate; the search is the activity. This file is the catalog.

Searched for an existing version Aaron mentioned ("you created it
and extended it and split into usefulness tiers") — could not
locate it in repo, drop/, or .playwright-mcp/. May exist in
Aaron's external notes (ChatGPT, Slack) or a previous session
that got lost. If a prior version surfaces, this file can be
merged with it (extend, don't replace).

Location classes covered:
1. Closed-not-merged PRs (most fertile)
2. Orphan branches (remote)
3. Deleted files in git history
4. Reflog entries (local-only)
5. Stash entries
6. Untracked working-directory artifacts
7. Subagent worktree remnants
8. GitHub draft PRs (unpublished)
9. Closed PR discussion threads
10. Squash-merge intermediate commits
11. Force-pushed-over content
12. Courier-ferry artifacts (drop/)
13. External-tool exports never committed
14. Deleted-PR-description content
15. Memory-file deletions (cross-tree drift)

Per Otto-293: "ask" not "directive" — bidirectional language.

Composes with: Otto-329 Phase 8 (the larger lost-files-search ask),
Otto-262 (trunk-based-development branch hygiene), Otto-257 (clean-
default smell triggers audit), Otto-238 (retractability — deletions
should leave visible trails), Otto-324 (mutual-learning — past
mistakes compound into substrate), tools/hygiene/audit-memory-
references.sh (already covers location-class #15), tools/hygiene/
audit-git-hotspots.sh (proxy for high-deletion-risk files).

Owed follow-up: tools/hygiene/audit-lost-files.sh executable form
covering all 15 survey commands.

Per Otto-327: ordinary substrate / hygiene catalog, not ambitious
empirical claim. Auto-merge default applies.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* fix(B-0019): #521 review-thread catches — orphan-branch survey corrected, name attribution → role-ref

Two valid catches resolved:

1. Orphan-branch survey command was wrong — comm-pipe just diffs
   name sets between GitHub branches and origin/* refs; doesn't
   actually check unmerged-status or no-PR-status. Replaced with:
   - Unmerged: `git for-each-ref --no-merged origin/main`
   - No-PR: comm vs gh pr list (corrected version)
   - True orphan = intersection of both

2. Name attribution "Aaron's ask" violates AGENT-BEST-PRACTICES
   "No name attribution in code, docs, or skills" since
   tools/hygiene/** is not an exempt history surface. Replaced
   with "Human maintainer ask"; full provenance lives in the
   matching memory/feedback_otto_329_*.md file (exempt history).

Per Otto-313 decline-as-teaching: both catches were correct;
applying fixes rather than declining is the right shape.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

…on (#636)

* tick-history: 18:02Z sync option-c COMPLETE + substrate transition

Sync work done. Task #284 marked completed.

Forward-sync PRs landed: #592 batch-1, #633 batch-2 (23 per-row-files), #634 batch-3 in CI, #635 batch-4. Batches 5+6 ALL SUPERSEDED-DISCARD per Otto-347 2nd-agent verify. Reverse-sync via Option C (close PR #15, UPSTREAM-RHYTHM cadence going forward).

Substrate yield exceeded sync output: ~12 memory files + 3 lineage anchors (harbor+blade=Radical Candor, SRE-as-Substrate-RE, Rodney's-Razor=Occam+Brooks+Kolmogorov+Bennett+Gell-Mann) emerged during the sync work. Otto-347 2nd-agent verify load-bearing in both directions (caught real loss on #618 + confirmed 7 SUPERSEDED calls).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* fix: standardize "Option C" casing in tick-history row 2026-04-26T18:02Z (Copilot P2)

Copilot P2 nit on PR #636: row mixed "option-c" (twice) and "Option C"
(once). Standardize on "Option C" across the row so later searches over
tick-history don't miss matches.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

…ard PinnedDependenciesID #15 #16)

elan.sh — switched from `curl ... master/elan-init.sh | sh` (latest
master, unpinned) to:
  1. Download elan-init.sh at v4.2.1 commit SHA
     (58e8d545e33641f66dbcbd22c4283109e71757be)
  2. Verify SHA256 (4bacca9502cb89736fe63d2685abc2947cfbf34dc87673504f1bb4c43eda9264)
  3. Execute the verified copy

linux.sh — switched from `curl mise.run | sh` (auto-detects latest at
runtime) to:
  1. Download the pinned tarball mise-v2026.4.24-linux-{x64,arm64}.tar.gz
     directly from github.com/jdx/mise/releases
  2. Verify per-arch SHA256 (x64: de2f924…2c58, arm64: cf5f4899…5727)
  3. Extract mise/bin/mise to ~/.local/bin and source PATH

Why this is a quality improvement, not just rule-appeasement:
- The previous shapes silently absorbed any new elan/mise release
  between CI runs. A compromised upstream master branch (elan) or a
  redirector swap (mise.run) would have shipped to every dev laptop
  + every CI run with no signal. Content-hash pinning makes such an
  event a hard fail with a verification message.
- Bumping is a deliberate two-line change (commit/tarball + hash)
  with a documented procedure in each script's comment block — easier
  to audit than `master`/`mise.run`.
- Portable SHA256 verification (sha256sum/shasum fallback) per
  Otto-235 4-shell target.

Per Aaron 2026-04-27: "preserve quality signals" — fix, don't relax.

Resolves Scorecard alerts #15 (elan downloadThenRun) and #16 (mise
downloadThenRun).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

…three-way-parity per Aaron 2026-04-27) (#653)

* ci: run lint-semgrep via SHA-pinned semgrep/semgrep Docker image (resolves Scorecard PinnedDependenciesID #17 #18)

Replaces `pip install --upgrade pip + pip install semgrep` with the
official semgrep/semgrep:1.161.0 image, pinned by multi-arch manifest
digest sha256:326e5f41cc972bb423b764a14febbb62bbad29ee1c01820805d077dd868fea48.

Why this is a quality improvement, not just rule-appeasement:
- Image bytes are content-addressed by digest. Tag mutation cannot
  affect us; the earlier `pip install semgrep` was version-floating
  and would silently pick up any new semgrep release between CI runs.
- Removes the entire pip-bootstrap surface (Setup Python +
  pip --upgrade + pip install semgrep). Smaller attack surface, faster
  CI, fewer pinning surfaces to maintain.
- Multi-arch index digest covers both x86_64 and arm64 runners.

Per Aaron 2026-04-27: "given we want high quality signals for future
AI training and we persision the PRs do you still agree?" — fix, do
not relax. This commit is the fix.

Resolves Scorecard alerts #17, #18 (PinnedDependenciesID, pipCommand).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* ci/setup: pin elan + mise installers by content hash (resolves Scorecard PinnedDependenciesID #15 #16)

elan.sh — switched from `curl ... master/elan-init.sh | sh` (latest
master, unpinned) to:
  1. Download elan-init.sh at v4.2.1 commit SHA
     (58e8d545e33641f66dbcbd22c4283109e71757be)
  2. Verify SHA256 (4bacca9502cb89736fe63d2685abc2947cfbf34dc87673504f1bb4c43eda9264)
  3. Execute the verified copy

linux.sh — switched from `curl mise.run | sh` (auto-detects latest at
runtime) to:
  1. Download the pinned tarball mise-v2026.4.24-linux-{x64,arm64}.tar.gz
     directly from github.com/jdx/mise/releases
  2. Verify per-arch SHA256 (x64: de2f924…2c58, arm64: cf5f4899…5727)
  3. Extract mise/bin/mise to ~/.local/bin and source PATH

Why this is a quality improvement, not just rule-appeasement:
- The previous shapes silently absorbed any new elan/mise release
  between CI runs. A compromised upstream master branch (elan) or a
  redirector swap (mise.run) would have shipped to every dev laptop
  + every CI run with no signal. Content-hash pinning makes such an
  event a hard fail with a verification message.
- Bumping is a deliberate two-line change (commit/tarball + hash)
  with a documented procedure in each script's comment block — easier
  to audit than `master`/`mise.run`.
- Portable SHA256 verification (sha256sum/shasum fallback) per
  Otto-235 4-shell target.

Per Aaron 2026-04-27: "preserve quality signals" — fix, don't relax.

Resolves Scorecard alerts #15 (elan downloadThenRun) and #16 (mise
downloadThenRun).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* ci: switch semgrep to mise-managed pipx:semgrep (three-way-parity per Aaron 2026-04-27)

Reverts the Docker-container approach in favour of the GOVERNANCE §24
three-way-parity invariant: dev laptops + CI runners + devcontainers
all install semgrep through the same `tools/setup/install.sh` via
mise. CI was the odd one out (had its own actions/setup-python + pip
install), which would have made switching CI hosts costly and broke
host-portability.

Aaron 2026-04-27:

> "actions/setup-python we should be using our base python that our
> install scripts install we are trying to not use github stuff
> unless we have to so it's easy to switch hosts and our dev machine
> and build machine setup is the same, that's one of the invariants
> we want to try to keep as close as possible dev machine / build
> machines are same/very similar for setup/share the setup/install
> scripts and post install scripts. this makes CI more deterministic
> too."

What changed:
- `.mise.toml`: added `pipx = "1.11.1"` (aqua-backed; same SHA-pinned
  release path as actionlint / shellcheck / uv) and
  `"pipx:semgrep" = "1.161.0"`. Now any machine that runs install.sh
  gets the same semgrep version pinned the same way.
- `.github/workflows/gate.yml` lint-semgrep: dropped the
  `container: semgrep/semgrep@sha256:...` block from the previous
  iteration; dropped `actions/setup-python` and the two `pip install`
  steps. Job is now: checkout → install.sh → semgrep. Same shape as
  build-and-test.

This still resolves Scorecard PinnedDependenciesID #17 + #18 (the
unpinned pip-bootstrap surface goes away entirely) and additionally:
- Restores host-portability — no GitHub-specific actions in this job
- First-class dev-laptop parity (semgrep was previously not actually
  installed by install.sh; now it is)
- More deterministic CI (mise resolves declarative pins; no
  pip dependency-resolver wandering)

Verified locally: `mise install` + `mise exec -- semgrep --version`
produces 1.161.0 on the same shape.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* ci: drop redundant pipx pin, bump uv to 0.11.8; document uv-canonical decision (Aaron 2026-04-27)

Removes `pipx = "1.11.1"` from `.mise.toml` — mise's `pipx:` backend
auto-routes through `uv tool install` when uv is available, so adding
pipx as a separate package was redundant. Bumps `uv` from 0.9 to
0.11.8 (latest, verified via gh API today 2026-04-27 — current
training data is stale per Otto-247 version-currency rule).

Adds:
- `docs/DECISIONS/2026-04-27-uv-canonical-python-tool-manager.md` —
  ADR documenting uv as the canonical Python tool manager for Zeta,
  the lineage from `../scratch` (where uv was made first-class
  first), the mise pipx:→uv auto-route behaviour, and the rules for
  using `pipx:foo` pins without an actual pipx package.
- `memory/feedback_three_way_parity_install_scripts_dev_ci_devcontainer_minimize_github_specific_surface_aaron_2026_04_27.md` —
  substrate memory naming Aaron's host-portability invariant; what
  three-way parity buys; what was almost violated by the
  Docker-container draft; the right-fix decision flow.
- MEMORY.md row pointing at the new memory + ADR.

Aaron 2026-04-27 verbatim:
- "we have uv do we need pipx, isn't there a uvx this should be much
  faster also +pipx = '1.11.1' is this latest, remember you mode
  cached latest can't be trusted you have to search the internet
  this goies for all version numbers you add, let's not start on an
  older version."
- "the fact that uv is our desired python setup should be documented
  somewehre this project ../scratch made it first class too"

Verified locally: `mise install` with `uv = "0.11.8"` +
`pipx:semgrep = "1.161.0"` (no separate pipx) installs semgrep
1.161.0 via uv tool install.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* ci/setup: address review feedback on #653 (cleanup traps, armv7, role-refs, stale comment)

7 review threads:

1. Copilot P1 — name attribution in gate.yml + .mise.toml comments
   ("Per Aaron 2026-04-27") violates the role-ref-on-current-state
   discipline (history surfaces only). Replaced with role-refs:
   "the host-portability invariant" / "per the three-way-parity
   invariant (GOVERNANCE §24)".

2. Codex P2 — preserve armv7 support that `curl mise.run | sh`
   used to give us implicitly. Added the armv7 case + SHA256
   to the per-arch dispatch in linux.sh.

3. Copilot P1 — temp dir leak on failure in linux.sh: `mktemp -d`
   only cleaned up on the success path. Added `trap 'rm -rf
   "${MISE_TMP}"' EXIT` so the dir is removed even on download /
   SHA / extract failure.

4. Copilot P1 — same pattern in elan.sh tmp file. Added EXIT
   trap.

5. Copilot P1 — gate.yml install-toolchain step comment claimed
   "mise installs python + pipx + semgrep" but pipx was dropped
   in commit d62fc6d (mise auto-routes pipx: through uv).
   Updated the comment to reflect current state and to point at
   the uv-canonical ADR.

6. Copilot P1 — same name-attribution issue in .mise.toml
   semgrep block. Replaced.

7. Copilot P1 — PR description was already updated; thread
   should be re-evaluated by reviewer with the current
   description in view.

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>

…do (Aaron 2026-04-27, clean branch) (#654)

* substrate: block on Aaron only when he MUST do something only he can do; weighty decisions same flow as non-weighty (Aaron 2026-04-27)

Composes #57 (protect-project) + #71 (Otto owns settings) + #56
(communication classification) + Otto-357 (no directives).

Triggered by today's Scorecard-alerts decision where Otto froze for
~6 idle ticks waiting for Aaron's call when the decision was Otto's
to make. Aaron course-corrected: "you didn't need to stop for this,
we could have bulk aligned later."

Threshold rule: block on Aaron iff Aaron must do something only he
can do (credentials, identity, personal time/trust calibration,
maintainer-personal hard-stops). Otherwise drive forward with best
long-term judgment + bulk-align later.

Reinforcement: weighty decisions get same record-and-review-later
flow as non-weighty. No special "weighty=block" tier. Otto's
existing memory + commit + PR-description pattern already records
non-weighty calls; weighty ones land the same way.

Re-files on a clean branch off current main (the original branch
was based off pre-bulk-sync main and had ~99 commits of conflict).

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

* review-fix(#654): replace ambiguous #NN refs with descriptive rule names; tighten MEMORY.md index entry (Copilot P1+P2)

Three P1 threads (Copilot) on the substrate memory file flagged the
(see docs/ISSUES-INDEX.md mapping). Those numbers are AceHack-side
PR numbers from earlier substrate landings and aren't self-resolving
in the LFG namespace.

Replaced each with its descriptive rule name:
- `#71` → "the Otto-owns-git/GitHub-settings rule"
- `#57` → "the protect-project critical-evaluation rule"
- `#56` → "the Aaron-communication-classification rule"
- `#69` → "the only-Otto-aware-agents-execute-code rule
   (pre-peer-mode execution authority)"

The remaining `#15-#18` references in the Forward-action section
are Scorecard code-scanning alert numbers (different namespace from
issues/PRs); left unchanged as they're unambiguous in context.

P2 thread (Copilot) on MEMORY.md flagged the new index entry as too
long. Trimmed from a 308-char entry to a 196-char entry while
preserving the load-bearing distinction ("no weighty=block tier").

Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>